Mon 03 Dec 2007
Tags: blosxom, blosxom plugins, microformats
Building on my initial set of blosxom microformat plugins,
the hcard plugin provides a global hcard
variable for inclusion in your blosxom templates.
To use it, you simply define the set of hcard data to use in an 'hcard.yml'
file in your blosxom data directory, and then include $hcard::hcard
somewhere in your blosxom flavours/template. An example hcard.yml for me
might be:
Name: Gavin Carr
Organisation: Open Fusion
Role: Chief Geek
Email: gavin@openfusion.com.au
URL: http://www.openfusion.net/
Suburb: Wahroonga
State: NSW
Postcode: 2076
Country: Australia
Latitude: -33.717718
Longitude: 151.117158
HCard-Class: nodisplay
HCard-Style: div-span
I'm using hcard here, so if you have microformat support in your browser
(e.g. via the Operator
plugin, if using firefox) you should be able to see my hcard on this page.
As usual, available in the
blosxom sourceforge CVS
repository.
Sat 01 Dec 2007
Tags: blosxom, blosxom plugins, microformats
I've been messing around recently with some ideas on adding some
initial microformats support to blosxom.
Microformats are fragments of html marked up with some standardised
html class names, providing a minimalist method of adding simple
structured data to html pages, primarily for machine parsing (try
out the firefox Operator
plugin to see microformats in action). Some examples of currently
defined microformats are contact details
(hcard), events
(hcalendar), links or bookmarks
(xfolk), geolocation
(geo), etc. See the main
microformats website for more.
With blosxom, one simple approach is to allow microformat attributes
to be defined within story metadata, and either autoappend the
microformat to the story itself, or simply define the microformat in
a variable for explicit inclusion in the story. So for example, if
you wanted to geocode a particular story, you could just add:
Latitude: -33.717770
Longitude: 151.115886
or
meta-latitude: -33.717770
meta-longitude: 151.115886
to your story headers (depending on which metadata plugin you're
using).
This is the initial approach I've taken, allowing you to attach
microformats to stories with a minimum of fuss. So far, the
following blosxom microformat plugins are available:
uf_adr_meta - adr supportuf_geo_meta - geo supportuf_hcalendar_meta - hcalendar supportuf_hcard_meta - hcard supportuf_xfolk_meta - xfolk support
Note that these are beta quality, and may well contain bugs.
Feedback especially welcome from microformat gurus. There's also
a lot of other ways we might like to handle or integrate
microformats - this is just a useful first step.
All plugins are available in
blosxom sourceforge CVS
repository.
Thu 08 Nov 2007
Tags: blosxom, blosxom plugins
I've been using tags here right from the beginning, because they
provide a much more powerful and flexible way of categorising
content than do simpler more static categories. This seems to be
pretty much the consensus in the blogosphere now.
I started off using xtaran's
tagging plugin. The one thing I
didn't like about tagging was that it has a fairly brute-force
approach to doing tag filtering - it basically just iterates over the
set of candidate files and opens up and checks them all, every time.
So I started messing around with adding some kind of tag cache to
tagging, so that the set of tags on a post could be captured
when a post was created or updated, and thereafter tag filtering
could be done by just referencing the tag cache. That means that
if you've got 100 posts, your tag query only needs to read one file -
the tag cache - instead of all 100 posts.
En route I realised I really wanted a more modular approach to
tagging than the tagging plugin uses as well. For instance, I'm
experimenting with various kinds of
data blogging, like using dedicated
special-purpose blogs for recording bookmarks or books or photos.
And for some of these blogs I wanted to be able to do basic tagging
and querying, but didn't need fancier interface stuff like
tagclouds.
So I've ended up creating a small set of blosxom plugins that
provide most of the functionality of tagging using a tag cache.
The plugins are:
tags - provides base tag functionality, including checking
for new and updated stories, maintaining the tag cache, and
providing tag-based filtering. Requires my metamail plugin.
storytags - provides a story level $storytags::taglist
variable containing a formatted list of tags, suitable for
inclusion in a story template. Requires tags.
tagcloud - provides a $tagcloud::cloud variable containing
a formatted wikipedia:"tagcloud" of tags and counts, suitable
for inclusion in a template somewhere. Requires a hashref of
tags and counts, which tags provides, but should be able to
work with other plugins.
Note that these plugins are typically less featureful than the
tagging plugin, and that tagging includes functionality
(related tag functionality, in particular) not provided by any
of these plugins. So tagging is still probably a good choice
for many people. Nice to have choice, though, ain't it?
All plugins are available in
blosxom sourceforge CVS
repository.
Tue 30 Oct 2007
Tags: blosxom, blosxom plugins
I've tried all three of the current blosxom 'entries' plugins on my
blog in the last few months: entries_cache_meta, entries_cache, and the
original entries_index.
entries_cache_meta is pretty nice, but it doesn't work in static mode,
and its method of capturing the modification date as metadata didn't quite
work how I wanted. I had similar problems with the entries_cache metadata
features, and its caching and reindexing didn't seem to work reliably for me.
entries_index is the simplest of the three, and offers no caching features,
but it's pretty dense code, and didn't offer the killer feature I was after:
the ability to easily update and maintain the publication timestamps it was
indexing.
Thus entries_timestamp is born.
entries_timestamp is based on Rael's entries_index, and like it offers
no caching facilites (at least currently). Its main point of difference
from entries_index is that it maintains two sets of creation
timestamps for each post - a machine-friendly one (a gmtime timestamp)
and a human-friendly one (a timestamp string).
In normal use blosoxm just uses the machine timestamps and works just like
entries_index, just using the timestamps to order posts for presentation.
entries_timestamp also allows modification of the human timestamps,
however, so that if you want to tweak the publish date you just modify
the timestamp string in the entries_timestamp.index metadata file, and
then tell blosxom to update its machine-timestamps from the human- ones by
passing a reindex=<$entries_timestamp::reindex_password> argument to
blosxom i.e.
http://www.domain.com/blosxom.cgi?reindex=mypassword
It also supports migration from an entries_index index file, explicit
symlink support (so you don't have to update timestamps to symlinked
posts explicitly), and has been mostly rewritten to be (hopefully)
easier to read and maintain.
It's available in the
blosxom sourceforge CVS
repository.
Mon 10 Sep 2007
Tags: blosxom, blosxom plugins
I've just released my first blosxom
plugin into the wild. 'mason_blocks' is a blosxom plugin implementing
simple conditional and comment blocks using
HTML::Mason-style syntax, for use in
blosxom flavour and template files.
Examples:
# Mason-style conditionals
% if ($pagetype::pagetype ne 'story') {
<a href="$permalink::story#comments">Comments ($feedback::count)</a>
% } else {
<a href="$permalink::story#leave_comment">Leave a comment</a>
% }
# Mason-style comments
%# Only show a comments section if there are comments
% if ($feedback::count > 0) {
$feedback::comments
% }
# Mason-style block comments
I wrote it when I couldn't get the interpolate_fancy plugin to work properly
with nested tags, and because I wanted proper perl conditions and if-else
support. mason_blocks provides all the conditional functionality of
interpolate_fancy, but not other stuff like 'actions'.
mason_blocks is available from the
blosxom plugins CVS repository.